][width=100%

sad

1. Proposta d’idea del projecte: AdMe

1.1 Introducció

AdMe és una aplicació per crear, buscar i compartir anuncis de particulars o autònoms basats en categories.

1.2 Ojectiu de l’app i quines necessitats resol

L’objectiu d’AdMe és posar en contacte oferents, particulars i autònoms de tota mena de serveis o compra-venda d’objectes, amb usuaris interessats. Permet als usuaris crear anuncis i compartir-los a través de l’app, així com buscar, filtrar i trobar ofertes o anuncis d’altres usuaris.

Aquesta aplicació respon a la necessitat d’un mercat mòbil senzill i dinàmic per a particulars i autònoms, oferint una plataforma on els usuaris poden anunciar-se o buscar ofertes de manera segura i transparent.

1.3 Estudi de mercat

I. Aplicacions similars

  • Wallapop: Wallapop és una aplicació per a la venda d’objectes de segona mà.

  • MilAnuncios: És una aplicació per oferir i buscar anuncis a internet.

II. Diferenciació

AdMe es centra en la simplicitat i la comunitat. A diferència d’altres plataformes més complexes, aquesta aplicació està dissenyada exclusivament per a dispositius mòbils, amb un sistema senzill de creació d’anuncis i una interfície intuïtiva basada en filtres i categories.

1.4 Target

El target d’AdMe és molt variat, arribant a un públic comprès entre els 18 i els 50 anys.

1.5 Ítem i categoria

  • Ítem: Anuncis o ofertes de qualsevol tipus.

  • Categoria: Categories dels diversos tipus i temes principals d’anuncis a l’aplicació.

1.6 Processos de negoci

  • Proposar noves categories: Els usuaris d’AdMe podran crear propostes de categories, aquestes no seran visibles en els llistats de categories ni poden ser usades fins que un administrador les activi, fent-les "Oficials".

2. Especificacio de requisits

2.1 Requisits funcionals

I. Gestio d’usuaris

Requeriments relacionats amb l’autenticació, perfil i accions generals dels usuaris.

  • RF01: Login. L’usuari ha de poder iniciar sessió a l’aplicació amb el seu correu electrònic i contrasenya i sempre que estigui activat.

  • RF02: Registre. L’usuari ha de poder registrar-se per poder utilitzar l’app. Un nou usuari enregistrat, per defecte està en estat desactivat.

  • RF03: Recuperar contrasenya. L’usuari ha de poder recuperar la contrasenya en cas d’oblit.

  • RF04: Editar perfil usuari. L’usuari ha de poder modificar les dades del seu perfil, inclosa la seva foto.

  • RF05: Logout. L’usuari ha de poder tancar la sessió de manera segura.

  • RF06: L’administrador ha de poder canviar l’estat (activat o desactivat) dels usuaris enregistrats.

  • RF07: L’administrador ha de poder eliminar un usuari.

  • RF08: L’administrador ha de poder llistar tots els usuaris.

  • RF09: L’administrador ha de poder modificar un usuari.

II. Gestio de categories

Requeriments relacionats amb la creació, visualització i gestió de Categories.

  • RF10: Crear nova categoria. l’usuari ha de poder crear una nova categoria de tipus “Proposta” per defecte que contingui com a mínim un nom, una imatge i una descripció.

  • RF11: Llistar categories. L’usuari ha de poder veure una llista de totes les categories existents de tipus “Oficial”.

  • RF12: Filtrar categories. L’usuari ha de poder cercar categories pel seu nom i veure els resultats ordenats alfabèticament.

  • RF13: Ampliar informació de categoria. L’usuari ha de poder seleccionar una categoria i veure tota la informació associada (nom, imatge i descripció).

  • RF14: Modificar categoria. Només l’usuari administrador ha de poder modificar el nom, la imatge, la descripció i el tipus (“Oficial”, “Proposta”) de qualsevol categoria.

  • RF15: Eliminar categoria. Només l’usuari administrador ha de poder eliminar una categoria, sempre que no tingui anuncis associats.

  • RF16: Filtrar anuncis per categoria. L’usuari ha de poder veure només els anuncis que pertanyen a una categoria seleccionada.

III. Gestio d’anuncis

Requeriments relacionats amb la creació, visualització i gestió anuncis.

  • RF20: Crear nou anunci. L’usuari ha de poder crear un nou anunci que contingui, com a mínim, una imatge, títol, descripció curta, preu, data de creació, autor, numero telefon autori categoria.

  • RF21: Llistar anuncis. L’usuari ha de poder veure una llista de tots els anuncis existents, mostrant-ne la imatge i títol, amb un botó per ampliar informació.

  • RF22: Filtrar anunci per camps. L’usuari ha de poder filtrar els anuncis basant-se en qualsevol dels camps disponibles dels anuncis (com el títol, l’autor, o la data de creació, entre d’altres).

  • RF23: Ordenar anuncis per camps. L’usuari ha de poder ordenar la llista dels anuncis segons qualsevol camp disponible, com el títol, la data de creació o l’autor.

  • RF24: Ampliar informació del anunci. L’usuari ha de poder veure tots els detalls d’un anunci seleccionat (títol, imatge, descripció, autor, data de creació.

  • RF25: Modificar anunci. Només l’usuari que ha creat un anunci, o l’administrador, han de poder modificar-ne la informació, excepte l’autor, la data de creació, les valoracions i els comentaris.

  • RF26: Eliminar anunci. Només l’usuari que ha creat un anunci, o l’administrador, han de poder eliminar-lo.

IV. Requisits de negoci

Requeriments de negoci addicionals per al funcionament de la nostra aplicació.

  • RF27: L’administrador a de poder “activar” o fer “Oficials” les propostes de categorías modificant les.(Les categories poden ser de 2 tipus: “Oficial” i “Proposta”).

  • RF28: L’administrador a de poder llistar totes les categories de tipus “Proposta”.

2.2 Proposta de millora

Proposem per a millorar en futures versions de l’aplicació una funció de xat a través la cual els usuaris puguin interactuar, conversar i negociar desde la mateixa aplicació.

2.3 Requisits no funcionals

I. Requisits Tècnics part frontend Mobile

  • RN01: L’aplicació s’ha de desenvolupar utilitzant l’IDE Android Studio, implementant el llenguatge Kotlin per crear una aplicació nativa compatible amb dispositius Android.

  • RN02: L’aplicació ha de tenir l’arquitectura MVVM (Model-View-ViewModel) i el ViewModel ha de gestionar l’estat de l’aplicació amb MutableStateFlow i StateFlow.

  • RN03: S’ha d’utilitzar Jetpack Compose per implementar la interfície gràfica.

  • RN07: S’ha d’utilitzar el git/gitlab per implementar el projecte en equip de forma òptima i adient.

  • RN08: S’han de fer servir les següents branques: main/master, developer i branques per features, bugfix, etc.

  • RN09: Tots els merges de funcionalitats s’han de fer per merge-request a developer.

  • RN10: Les branques fusionades s’eliminen després del merge-request.

II. Requisits d’Interfície (UI/UX, Accessibilitat) frontend Mobile

  • RN11: L’app ha d’estar en català, castellà i anglès.

  • RN12: La interfície de l’usuari ha de complir amb les directrius de disseny Material Design. El disseny visual ha de ser atractiu amb coherència de colors, fonts, icones, bona distribució i agrupació de components. Mateix disseny per totes les pantalles.

  • RN13: Responsive: En cas de variar la grandària de la pantalla del mòbil (no cal per tablet), s’ha d’adaptar el contingut de forma proporcionada.

  • RN14: Usabilitat (UX): Interfície amigable, efectiva, intuïtiva i eficient. No pot haver-hi passos innecessaris entre el que vols fer i com fer-ho. Ha de quedar molt clar què es pot fer. També cal que tingui coherència amb les funcionalitats disponibles i no disponibles en cada moment.

  • RN15: App accessible: Els elements interactius han de tenir etiquetes descriptives per facilitar-ne l’ús.

  • RN16: S’ha d’utilitzar el menú Bottom Navigation per a la navegació a les funcionalitats principals.

III. Requisits operatius frontend Mobile

  • RN17: L’app s’ha de poder executar en qualsevol emulador o dispositiu mòbil amb sistema operatiu Android.

  • RN18: Fluïdesa: L’app ha de respondre a les entrades de l’usuari en tot moment. Això vol dir que en cap cas pot quedar “congelada” mentre realitza qualsevol operació.

  • RN19: Gestió d’excepcions: Totes les possibles situacions excepcionals han de quedar gestionades de forma correcta i proporcionar missatges d’errors descriptius i útils per a l’usuari quan falli.

  • RN20: El codi ha de ser optimitzat, eficient i sense redundàncies.

  • RN21: S’han d’utilitzar les classes, interfícies i mètodes i packages de forma òptima i adient. RN22: Qualsevol entrada per teclat per part de l’usuari ha de validar-se i filtrar-se per garantir que les dades recollides siguin correctes, coherents i segures.

  • RN23: Totes les capçaleres de mètodes i classes han d’estar degudament comentades en format JavaDOC.

  • RN24: Els logs han d’estar disponibles per al monitoratge i depuració.

  • RN25: L’aplicació ha de garantir que només els usuaris amb els permisos adequats puguin accedir a determinades funcionalitats.

  • RN26: La capa presentació ha d’estar ubicada en el frontend Mobile.

  • RN27: La comunicació entre el frontend Mobile i el backend s’ha de portar a terme mitjançant els principis REST

  • RN28: L’administrador pot fer totes les funcionalitats.

IV. Requisits backend

  • RN40: Les capes de servei, lógica de negoci i de persistència han d’estar ubicades al backend.

  • RN42: El backend s’ha d’implementar mitjançant SpringBoot.

3. Guions per actors

3.1 Usuari Anonim

Actor Usuari Anonim

Descripció

Aquest actor representa un usuari que encara no s’ha autenticat independentment de si s’ha registrat prèviament i no té accés a l’aplicació, només al login i registre.

Guió

RF01: L’usuari anònim pot iniciar sessió amb correu i contrasenya i sempre que estigui activat.

RF02: L’usuari anònim pot registrar-se per poder utilitzar l’app. (estara per defecte desactivat).

3.2 Usuari autenticat

Actor Usuari autenticat

Descripció

Aquest actor representa un usuari que s’ha autenticat havent-se registrat prèviament i té accés a les funcionalitats bàsiques de l’aplicació.

Guió

RF03: L’usuari pot recuperar la contrasenya en cas d’oblit.

RF04: L’usuari pot editar el seu perfil (incloent foto). RF05: Logout. L’usuari ha de poder tancar la sessió de manera segura.

RF10: Crear noves categories amb nom, imatge i descripció.

RF11: Veure la llista de categories existents.

RF13: Ampliar informació de categories seleccionades (nom, imatge i descripció).

RF16: Veure anuncis agrupats per categories seleccionades.

RF20: Crear nous anuncis amb detalls (imatge, títol, descripció, preu, categoria, etc.).

RF21: Veure una llista de tots els anuncis existents.

RF22: Filtrar anuncis basant-se en camps específics.

RF23: Ordenar anuncis segons camps (data, autor, etc.).

RF24: Ampliar informació d’un anunci seleccionat.

RF25: Modificar anuncis creats per l’usuari.

RF26: Eliminar anuncis creats per l’usuari.

3.3 Administrador

Actor Administrador

Descripció

Aquest actor té tots els permisos incloent permisos especials per gestionar l’aplicació.

Guió

RF03: L’usuari autenticat pot recuperar la contrasenya en cas d’oblit.

RF04: L’usuari autenticat pot editar el seu perfil (incloent foto).

RF05: Logout. L’usuari ha de poder tancar la sessió de manera segura.

RF06: Activar o desactivar usuaris registrats.

RF07: Eliminar usuaris.

RF08: Llistar tots els usuaris.

RF09: Modificar dades dels usuaris.

RF10: Crear noves categories amb nom, imatge i descripció.

RF11: Veure la llista de categories existents.

RF13: Ampliar informació de categories seleccionades (nom, imatge i descripció).

RF14: Modificar categories existents.

RF15: Eliminar categories sense anuncis associats.

RF16: Veure anuncis agrupats per categories seleccionades.

RF20: Crear nous anuncis amb detalls (imatge, títol, descripció, preu, categoria, etc.).

RF21: Veure una llista de tots els anuncis existents.

RF22: Filtrar anuncis basant-se en camps específics.

RF23: Ordenar anuncis segons camps (data, autor, etc.).

RF24: Ampliar informació d’un anunci seleccionat.

RF25: Modificar anuncis creats per altres usuaris.

RF26: Eliminar anuncis creats per altres usuaris.

RF27: Poder “activar” o fer “Oficials” les propostes de categorías.

RF28: Poder llistar totes les categories de tipus “Proposta”.

4. Diagrames

5. Especificacions casos d’ús de negoci

Aquestes son les especificacions dels casos d’ús de negoci que s’han validat en la fase de proposta.

CU10

cu10

CU11

cu11

5.1. Altres especificacions casos d’ús

Aquest son alguns exemples de casos d’ús (CU1 - CU9).

CU1

cu1

CU2

cu2

CU3

cu3

CU4

cu4

CU5

cu5

CU6

cu6

CU7

cu7

CU8

cu8

CU9

cu9

6. Disseny de pantalles

6.1 Pantalles

Inici Sessió

105846

Recuperar contrasenya

105925

Home

105945

Proposta Anunci

110002

Llista Anuncis

110020

Perfil Usuari

110043
110059

Llista Usuaris

110115

Proposta Categories

110136

Crear Anunci

110159

6.2 Guia d’estils

estils

6.3 Components i botons

botons

7. Disseny de la Base de dades

7.1 Justificació BBDD

El disseny de BBDD que hem escollit és de Base de dades relacional amb (SQL), la nostra decisió es basa en els següents punts principals:

  • La proposta de negoci: La nostra proposta de negoci és més simple d’aplicar en una BBDD relacional com SQL.

  • Practica i experiencia: Estem més acostumats a treballar amb BBDD relacionals com SQL i, per tant, tenim molta més pràctica i experiència, cosa que facilitaria la resolució de problemes futurs.

  • BBDD no relacional no requerida: No és necessari per a cap aspecte de la nostra app utilitzar una BBDD no relacional com MongoDB.

7.2 Diagrama del disseny de la BBDD

dissenyDiagramaBBDD

Seguiment dels sprints

Sprint 1

1. Planificació Trello

2. Dialy stand up

daily6
daily10
daily11
daily12
daily13

3. Anàlisi del treball individual.

Carlos

  • Hores dedicades: 28h

  • Tasques realitzades

    • Entitat User backend

    • Entitat Ad backend

    • Entitat Category backend

    • Entitat User frontend

    • Entitat Ad frontend

    • Entitat Category frontend

    • Registre

    • Compose ProfileScreen

    • Login

    • Llistar Usuaris

    • Test User

  • Aspectes positius del treball realitzat

Alt rendiment i Eficacía a l’hora de completar les tasques, rapida resolucio de problemes.

  • Problemes trobats durant l’sprint

problemes menors que son mes deguts a errors de codi o problemes temporals poc importants de planificacio del sprint.

  • Accions concretes per aplicar millores en els següents sprints

aplicar els coneixements adquirits en el sprint per a solucionar futurs problemescde planificació.

Toni

  • Hores dedicades: 24h

  • Tasques realitzades

    • Test Ad

    • Test Category

    • Llistar Categories

    • LListar Ads per Categories

    • Entitat Ad frontend

    • Entitat Category frontend

  • Aspectes positius del treball realitzat

Eficaç i tenacitat a l’hora d’afrontar les tasques

  • Problemes trobats durant l’sprint

Algunes resolucions als problemes i dificultats trobades y superades en les tasques poden generar problemes de codi i son poc intuitius

  • Accions concretes per aplicar millores en els següents sprints

Asegurarse de que les seves resolucions de bugs del codi no afectin a altres parts d’aquest

David

  • Hores dedicades: 34h

  • Tasques realitzades

    • Estructura Packages Graddle a Android Studio

    • Test Category (Fix)

    • Test Ad (Fix)

    • Test User (Fix)

    • Asciidoc memoria sprint 1

  • Aspectes positius del treball realitzat

Eficacia a l’hora de resoldre errors de codi i qualitat en aquestes resolucions

  • Problemes trobats durant l’sprint Baixa asistencia a clase sobretot a primera hora lo que dificulta la coordinacio i assignació de tasques, problemes de compatibilitat de llibreries com Lombok

  • Accions concretes per aplicar millores en els següents sprints

Aumentar la asistencia a clase y a primera hora aixi com aumentar la coordinacio de tasques

Sprint 2

1. Planificació Trello

2. Dialy stand up

dialy16
daily17
daily18
daily19

3. Anàlisi del treball individual.

Carlos

  • Hores dedicades: 22h

  • Tasques realitzades

    • Crear ProfileScreen

    • Recuperar contraseña

  • Aspectes positius del treball realitzat

Alt rendiment i Eficacía a l’hora de completar les tasques, rapida resolucio de problemes.

  • Problemes trobats durant l’sprint

No s’han produit errors destacables

  • Accions concretes per aplicar millores en els següents sprints

seguir aplicant els coneixements adquirits en el sprint per a solucionar futurs problemes de planificació.

Toni

  • Hores dedicades: 17h

  • Tasques realitzades

    • Barra navegacio inferior

    • Modificar Ads

    • Crear Ads

  • Aspectes positius del treball realitzat

Eficaç i efectiu a l’hora de treballar en grup

  • Problemes trobats durant l’sprint

No hi ha agut porblemes destacables

  • Accions concretes per aplicar millores en els següents sprints

seguir Asegurantse de que les seves resolucions de bugs del codi no afectin a altres parts d’aquest

David

  • Hores dedicades: 19h

  • Tasques realitzades

    • Crear Categories

    • Crear Propostes

  • Aspectes positius del treball realitzat

Eficacia a l’hora de resoldre errors del codi i puliment del codi

  • Problemes trobats durant l’sprint

No s’han produit problemes destacables

  • Accions concretes per aplicar millores en els següents sprints

Seguir asistint a clase com ha fet l’ultima setmana y amb el nivell de treball

Sprint 3

1. Planificació Trello

2. Dialy stand up

daily20
daily24
daily25
daily26

3. Anàlisi del treball individual.

Carlos

  • Hores dedicades: 22h

  • Tasques realitzades

    • Crear usuari desde admin

  • Aspectes positius del treball realitzat

Alt rendiment i Eficacía a l’hora de completar les tasques, rapida resolucio de problemes.

  • Problemes trobats durant l’sprint

No s’han produit errors destacables

  • Accions concretes per aplicar millores en els següents sprints

seguir aplicant els coneixements adquirits en el sprint per a solucionar futurs problemes de planificació.

Toni

  • Hores dedicades: 13h

  • Tasques realitzades

    • Mostrar info venedor anuncis

    • Logica crear anucnis

    • Resolucio d’errors anuncis Backend

  • Aspectes positius del treball realitzat

Eficaç i efectiu a l’hora de treballar en grup

  • Problemes trobats durant l’sprint

No hi ha agut porblemes destacables

  • Accions concretes per aplicar millores en els següents sprints

seguir Asegurantse de que les seves resolucions de bugs del codi no afectin a altres parts d’aquest

David

  • Hores dedicades: 24h

  • Tasques realitzades

    • Llistar Propostes Screen

    • Activar propostes

    • Resolucio d’errors categories Backend

  • Aspectes positius del treball realitzat

Eficacia a l’hora de resoldre errors del codi i puliment del codi

  • Problemes trobats durant l’sprint

No s’han produit problemes destacables

  • Accions concretes per aplicar millores en els següents sprints

Seguir asistint a clase com ha fet l’ultima setmana y amb el nivell de treball